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FTP Command and Extension Registry 
Abstract 


Every version of the FTP specification has added a few new commands, 
with the early ones summarized in RFC 959. RFC 2389 established a 
mechanism for specifying and negotiating FTP extensions. The number 
of extensions, both those supported by the mechanism and some that 
are not, continues to increase. An IANA registry of FTP Command and 
Feature names is established to reduce the likelihood of conflict of 
names and the consequent ambiguity. This specification establishes 
that registry. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc5797. 
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1. Introduction 


Every version of the FTP specification has added a few new commands, 
with the early ones summarized in RFC 959 [RFC0959]. RFC 2389 
[RFC2389] established a mechanism for specifying and negotiating 
extensions to the FTP protocol specified in RFC 959, by means of 
"FEAT Strings" identifying extensions supported by the FTP server, 
and sent in response to a "FEAT" command. The number of extensions 
continues to grow, not all of them supported by FEAT. An IANA 
registry is established to reduce the likelihood of a conflict of 
names and the consequent ambiguity and to encourage the sharing of 
information. This specification establishes that registry. 


2. Registry Definition 

2.1. Registry Name 
The name of this registry is "FTP Commands and Extensions". 

2.2. Registry Format 
As specified in this RFC, IANA has established a registry for FTP 
commands and extensions. Registration requests and registry entries 


should include the following: 


Command Name - The FTP command, either new or modified, used in the 
extension or with which the extension is used. 


Following the long-standing practice to capitalize command names 


in specification documents for FTP, the command names are entered 
in all uppercase. For extensions amending the operation of a 
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command, a plus sign ("+") is appended to the command name. 
However, if an extension affects the overall command parameter 
handling and/or transaction processing, instead of being bound to 
one command (or a small number of commands), the string "-N/A-" is 
entered. 


It is intended to have the registry entries ordered by ascending 
ASCII collation order of this column (including the "+" suffix if 
present). 


Extension name - The name of the extension. 


FTP extensions predating RFC 2389 [RFC2389], and some extensions 
published after it, did not specify a keyword to identify the 


extension in a FEAT response. Some later specifications 
established FEAT strings with the respective command names as 
their keywords. In order to provide for keywords for future 


specifications in such cases, this document establishes 
‘placeholder’ keywords to reserve reasonable feature names for 


future standardization. Similarly, placeholder keywords are used 
for the basic FTP commands specified in RFC 959 [RFC0959] and 
those of its predecessors that are still in use. These 


placeholder keywords are placed in the registry for convenience; 
it is not intended that they be returned in FEAT responses. 

To compensate for this idiosyncrasy, the column in the registry is 
entitled "FEAT Code", and to clearly distinguish between the two 
cases, defined FEAT keywords codes are listed in all uppercase, 
whereas placeholder keywords (henceforth called "pseudo FEAT 
codes") are listed in lowercase. Future specifications are 
allowed to "upgrade" a placeholder to a true keyword unless it is 
specifically declared ’immutable’ below, but otherwise IANA 
maintains uniqueness of feature names (FEAT codes) based on case- 
insensitive comparison. 


Description - A brief description of the extension and, where 
appropriate, the command. 


FEAT String - (optional in registration requests to IANA) 


The string expected to be included in the response to the FEAT 
command [RFC2389] if the extension is supported. 


In many cases, the FEAT string required to identify an extension 
only consists of the "FEAT Code", making this item redundant. 
Therefore, this item should only be specified if it is intended to 
register a FEAT string that contains mandatory elements other than 
the "FEAT Code" itself. 
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Due to space restrictions, and to allow registrants to provide 
additional information, IANA should present these registration 
items (if given) in numbered footnotes to the table, not in an 
additional table column. 


Command Type - The type (or /’kind’) of the command. 


Section 4.1 of RFC 959 [RFC0959] introduced a subdivision of FTP 
commands into three types: Access control, transfer Parameter 
{setting}, and Service {execution}. For clarity, and as a service 
to the user of the registry, this subdivision is extended to all 
registered FTP commands, using the characteristic initial of the 
type, ’a’, ‘'p’, or 's’, respectively, filed in the registry column 
titled "type"; combinations are allowed, e.g., 'p/s’. 


Conformance Requirements - The support expectation for the command. 


RFC 959 specifies mandatory-to-implement commands and optional 
commands. This classification is carried over to all registered 
commands, using a column titled "conf" carrying a single character 
—-- either ’m’ or ’o’, for "mandatory" and "optional", 
respectively. Similarly, obsoleted or historic entries are left 
in the registry to avoid conflicts with deployed implementations, 
and these entries are marked with ’h’ (for "historic"). 

Beyond the initial registrations, Standards Action [RFC5226] is 
needed to register new "mandatory" entries or to move such entries 
to "hastorre™.; 


Reference - A reference to an RFC or other definition of the 


273A 


extension and/or to implementations supporting it (see the next 
section). 


Criteria for Registration 


This registry is primarily intended to avoid conflicting uses of the 
same extension names and command keywords for different purposes, not 
to demonstrate that an extension is somehow "approved". The "Expert 
Review" method will be used, but the designated expert is expected to 
check only that at least one of the two criteria that follow are met. 


T; 


The extension is documented in a permanent and readily available 
public specification (this is the same as the "Specification 
Required" registration policy defined in RFC 5226 [RFC5226]). 


The extension is actually implemented in FTP client and server 
systems that are generally available (not necessarily either free 
or unencumbered, but available). 
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For an extension or command to be marked "mandatory" (’m’ in the 
"conf" column), an IETF Standards Track specification is required. 
An IESG Standards Action is allowed to direct IANA to change the 
Conformance Requirements listed for any entry. 


2.4. Base FTP Commands 


The following commands are part of the base FTP specification 
[RFC0959] and are listed in the registry with the immutable pseudo 
FEAT code "base". 


Mandatory commands: 
ABOR, ACCT, ALLO, APPE, CWD, DELE, HELP, LIST, MODE, NLST, NOOP, 


PASS, PASV, PORT, QUIT, REIN, REST, RETR, RNFR, RNTO, SITE, STAT, 
STOR, STRU, TYPE, USER 


Optional commands: 
CDUP, MKD, PWD, RMD, SMNT, STOU, SYST 


Note: STD 3 [RFC1123] clarified and updated the status and 
implementation requirements of these standard FTP commands, and it 
contains important complementary information for the following 
commands: 


LIST, NLST, PASV, REST, SITE, STOU 
2.5. Obsolete Commands 


The following commands were specified as experimental in an extension 
to an early version of the FTP specification [RFC0O775] but later 
deprecated by RFC 1123 [RFC1123], because Standard FTP [RFC0959] 
specifies their standard successors. They are listed in the registry 
with the immutable pseudo FEAT code "hist". 


XCUP, XCWD, XMKD, XPWD, XRMD 


Implementation note: Deployed FTP clients still make use of the 
deprecated commands and most FTP servers support them as aliases 
for the standard commands. 


The following commands were specified as part of the "FOOBAR" IPng 
effort in RFC 1545 [RFC1545] and, later, RFC 1639 [RFC1639] and are 
now obsolete. They are listed in the registry with the immutable 
pseudo FEAT code "hist". 


LPRT, LPSV 
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FTP Command and Extension Registry 


Initial Contents of Registry 


March 2010 


As a service to users of the registry and the authors of existing 

all FTP commands and features published in RFCs after 
and up to the time of this writing were included in 
the registry upon creation. 


specifications, 
[RFC1123] 


STD 3 


The following pseudo FEAT codes have been assigned, 


according to 


Section 2: 
base - FTP standard commands [RFC0959] 
hist - Historic experimental commands [RFC0775], [RFC1639] 
secu - FTP Security Extensions [RFC2228] 
feat - FTP Feature Negotiation [RFC2389] 
nat6 - FTP Extensions for NAT/IPv6 [RFC2428] 
+------- 4+------4------------------- +-----—- +------ 4+------------------ + 
| cmd | FEAT | description | type | conf | RFC#s/References | 
| | Code | | | | and Notes | 
4+------- +----- 4$------------------- +------ +------ +------------------ + 
| ABOR | base | Abort | s | m | 959 
ACCT base Account a m 959 
| ADAT secu | Authentication/ | a | o | 2228, 2773, 4217 | 
| | | Security Data | | | | 
| ALLO | base | Allocate | s | m | 959 
| APPE | base | Append (with | s | m | 959 
| | | create) | | | | 
AUTH secu Authentication/ a fe) 2228 
| | Security | | | | 
| | | Mechanism | | | | 
| AUTH+ | AUTH | Authentication/ | a Lee | 2773, 4217 #2 | 
| | | Security | | | | 
| | | Mechanism | | | | 
CCC secu Clear Command a fe) 2228 
| | Channel | | | | 
| CDUP | base | Change to Parent | a | o | 959 | 
| | | Directory | | | | 
| CONF | secu | Confidentiality | a Me | 2228 | 
| | | Protected Command | | | | 
| CWD | base | Change Working | a | m | 959 | 
Directory 
| DELE | base | Delete File | s | m | 959 
| ENC | secu | Privacy Protected | a | o | 2228, 2773, 4217 | 
| | | Command | | | | 
| EPRT | nat6 | Extended Port | p lð | 2428 
| EPSV nat6é | Extended Passive | p | fe) | 2428 | 
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| FEAT | feat 
| | 
HELP base 
LANG UTF8 
| | 
| LIST | base 
| LPRT | hist 
| | 
| LPSV | hist 
| MDTM | MDTM 
| | 
| MIC | secu 
| | 
| MKD | base 
| MLSD | MLST 
| MLST | MLST 
| | 
| MODE | base 
| NLST | base 
NOOP base 
OPTS feat 
| PASS | base 
| PASV | base 
| PBSZ | secu 
| | 
| PBSZt+ | PBSZ 
| PORT | base 
| PROT | secu 
| | 
| PROT+ | PROT 
| PWD | base 
| QUIT | base 
| REIN | base 
| REST | base 
| REST+ | REST 
| RETR | base 
| RMD | base 
| RNFR | base 
| RNTO | base 
| SITE | base 
SIZE SIZE 
SMNT base 
| STAT | base 
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Feature 
Negotiation 
Help 

Language (for 


Server Messages) 
List 

Data Port 
{FOOBAR} 

Passive Mode 
{FOOBAR} 

File Modification 
Time 

Integrity 
Protected Command 
Make Directory 
List Directory 
(for machine) 
List Single 
Object 

Transfer Mode 
Name List 

No-Op 

Options 

Password 

Passive Mode 
Protection Buffer 
Size 

Protection Buffer 
Size 

Data Port 

Data Channel 
Protection Level 
Data Channel 
Protection Level 
Print Directory 
Logout 
Reinitialize 
Restart 

Restart (for 
STREAM mode) 
Retrieve 

Remove Directory 
Rename From 
Rename From 

Site Parameters 
File Size 
Structure Mount 
Status 
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| STOR | base | Store | s | m | 959 
| sTOU | base | Store Unique | a | o | 959, 1123 
STRU base File Structure p m 959 | 
SYST base System s fe) 959 
| TYPE | base | Representation | p | m | 959 #4 
| | | Type | | | | 
| USER | base | User Name | a | m | 959 
| xcUP | hist | {precursor for | s | h | 775, 1123 | 
CDUP } 
XCWD hist {precursor for s h 775, 1123 
| | | cw} | | | | 
| XMKD | hist | {precursor for | s | h i TIS- i1123 | 
| | | MKD) | | | | 
| XPWD | hist | {precursor for | s | h l TiS T123 | 
| | | PWD} | | | | 
XRMD hist {precursor for s h 775, 1123 
pe | am ie fl | 
| -N/A- | TvFS | Trivial Virtual | p | o | 3659 | 
| | | File Store | | | | 
+------- +------ +------------------- +------ +------ +------------------ + 
Table 1 
Notes: 


#1 While an IETF Standards Action would be required to make the FEAT 
mechanism [RFC2389] mandatory, implementation of that extension 
mechanism is clearly required in conjunction with any extension or 
feature that depends on it. 

#2 FEAT String for [RFC4217]: AUTH TLS 
FEAT String for [RFC2773]: AUTH KEA-SKIPJACK 

#3 FEAT String: REST STREAM 

#4 FEAT String: TYPE {semicolon-separated list of supported types} 
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IANA Considerations 


IANA has established the registry described in Section 2 using the 
initial content specified in Section 3 and including the body of 
Sections 2.4 and 2.5 as explanatory text in the preface of the 
registry. 


New entries should be added to this registry when extensions to FTP 
are approved or defined in RFCs or when extensions that are already 
in use and well-documented are identified. In other words, the 
requirement for registration is a slightly relaxed version of 
"Specification Required" [RFC5226] with Expert Review. See 

Section 2.3 for specifics and exceptions. 


Security Considerations 

The creation of this registry provides improved documentation and 
protection against interoperability problems. It introduces no new 
security issues. 
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